Today I used some simple aliases a colleague of mine added to the set of aliases of our project with the Alias Maven Plugin. Although the shortcuts seemed rather simple and negligible at first glance

rpr

instead of

mvn -T 4 release:prepare

they proofed astonishing useful. I was even so bold to run

r

instead of

mvn -T 4 release:prepare release:perform

For those of you who are not familiar with our alias plugin who may ask: "But how should I remember all those aliases?": Simply type

h

in your console.

 --- project-release
 r   = mvn -T 4 release:prepare release:perform [args]
 rpr = mvn -T 4 release:prepare [args]
 rpe = mvn -T 4 release:perform [args]
 rc  = mvn release:rollback [args]
 rc  = mvn release:clean [args]

The Alias Maven Plugin allows to specify aliases with their documentation as an XML file and generate alias scripts to various (two actually ;-): windows and bash) platforms.

You can find this configuration (with some other aliases) at config-smartics-alias.

Have a look and tell us, what you think -- if you like!

I have introduced our Buildmetadata Maven Plugin in my previous post Buildmetadata. Now I want to add some bits of information about what buildmetadata is about. Every artifact published by smartics contains this information.

The manifest file contains, besides the SCM properties, the usual information you find in Java archive files (JARs):

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Build-Jdk: 1.6.0_20
Specification-Title: maven-buildmetadata-plugin
Specification-Version: 1.1.1-SNAPSHOT
Specification-Vendor: smartics
Implementation-Title: maven-buildmetadata-plugin
Implementation-Version: 1.1.1-SNAPSHOT
Implementation-Vendor-Id: de.smartics.maven.plugin
Implementation-Vendor: smartics
Built-By: robert.reiner
Built-OS: Windows 7 / amd64 / 6.1
Implementation-Date: 26.09.2010 01:49:56
Implementation-DatePattern: dd.MM.yyyy HH:mm:ss
Implementation-Full-Version: 1.1.1-20100926r9401-SNAPSHOT
Implementation-SCM-Revision-Date: 26.09.2010 01:45:33
Implementation-SCM-Revision-Number: 9401
Implementation-Timestamp: 1285458596530
Implementation-URL: http://www.smartics.eu/public/de.smartics.mave
 n.plugin/maven-buildmetadata-plugin/1.1.1-SNAPSHOT
Java-Vendor: Sun Microsystems Inc.
Java-Version: 1.6.0_20
Maven-Version: 2.2.1

In this case the SCM information is actually useful if you want to access the sources of the artifact. As this example shows, the sources for the snapshot artifact are located on the SVN server with revision number 9401.

The details can be found in the build.properties file that is also located in the META-INF folder of the JAR file.

#Created by maven-buildmetadata-plugin.
#Sun Sep 26 01:50:03 CEST 2010
build.copyright.year=2006-2010
build.date=26.09.2010 01\:49\:56
build.date.pattern=dd.MM.yyyy HH\:mm\:ss
build.host.name=Asgard
build.java.compiler=HotSpot 64-Bit Server Compiler
build.java.runtime.name=Java(TM) SE Runtime Environment
build.java.runtime.version=1.6.0_20-b02
build.java.vendor=Sun Microsystems Inc.
build.java.vm=Java HotSpot(TM) 64-Bit Server VM
build.maven.execution.goals=clean, deploy, site-deploy
build.maven.execution.isRoot=true
build.maven.execution.profile.active.basic-user=settings.xml
build.maven.execution.profile.active.nexus=settings.xml
build.maven.execution.profiles.active=nexus, basic-user
build.maven.version=2.2.1
build.os.arch=amd64
build.os.name=Windows 7
build.os.version=6.1
build.scmLocallyModified=false
build.scmRevision.date=26.09.2010 01\:45\:33
build.scmRevision.id=9401
build.scmRevision.url=scm\:svn\:https\://www.smartics.de/svn/public/maven/maven-buildmetadata-plugin/trunk
build.timestamp.millis=1285458596530
build.user=robert.reiner
build.version=1.1.1-SNAPSHOT
build.version.full=1.1.1-20100926r9401-SNAPSHOT
build.year=2010

Here is also the URL to the SCM server for the snapshot artifact. If there is more than on SVN server around, you can stop guessing where the sources are actually located.

You also find a bit more detailed information about the runtime. But what may be especially useful is the mentioning of the profiles that have been activated during the build. In this example the profiles nexus and basic-user in the user's settings.xml were active. While this is of little value 2 years after the artifact has been deployed (since the settings.xml in a user's home directory is seldom in version control), it gives a hint at configuration information if a problem has been encountered during the development of the SNAPSHOT release.

All this information is not consulted every day. Most of the time, it is not consulted at all. But if a project encounters a problem with an artifact, information about who created it (whom may I ask questions?), at what machine/OS (encoding anyone?), with what Java version (used Java 7 instead of Java 5?) may proof helpful in desperate situations. Since the information is collected automatically and can be configured to the team's needs, you may want to give it a try.

We find it useful to define a versioning for our project and document it. Users of our products may then extract information about changes simply by comparing version numbers and look them up in the release reports or on our issue tracking server.

Release information provided by a Bugzilla server can be easily added with the use of our Issues Maven Plugin.

The administration of versions and milestones on a Bugzilla server can be done very conveniently with the Bugzilla Maven Plugin. Please have a look at the best practices on using this plugin.

Versioning Rules

Simple Versioning Scheme

We use the following versioning scheme.

The version consists of a major, a minor and a micro number (e.g. 1.23.42). For snapshot versions (current builds before a release), the qualifier SNAPSHOT is appended (e.g. 1.23.42-SNAPSHOT).

The parts of the version number have the following meaning.

Major Release Zero

For major releases with version number zero we handle the Simple Versioning Scheme less strict. The reason for this is that at the beginning of a project, the development is often experimental. Things work, some things don’t, some need small changes, some bigger ones.

To respect this evolutionary design we do not want to change the major release version until we regard the product as stable and shippable. Therefore, for projects in their major version number zero state compatible changes are reflected by changing the micro version, while changing the minor version may include new features and the removal of obsolete features. Incompatible changes are mentioned in the breaking news report.

Resources

• APR’s Version Numbering, Apache Portable Runtime (APR) Project
• Software versioning @ wikipedia
• This article was originally posted 2010 on our project website.

Hint for Maven users: The Versions Maven Plugin may proof useful in managing version numbers for multi projects.

Edit, 10/2012: There is a specification for this form of versioning called semantic versioning. This specification gives a deeper insight into the versioning scheme and its consequences than our short blog post here:

• Semantic Versioning
• Semantic Versioning -Technical Whitepaper – (PDF) OSGi Alliance
• About Versions – posted at Software Simplexity by Peter Kriens